Fix remaining ty static type checker warnings and errors. - #139

🔴 [High] EccPrivate.encode_key() accepts with_curve but silently ignores it

To silence ty's invalid-method-override, the signature of EccPrivate.encode_key was widened from (self) -> bytes to (self, with_curve: bool = True) -> bytes, but the body was not touched. It still calls _lib.wc_EccKeyToDer(self.native_object, key, len(key)). Per the CFFI cdef in scripts/build_ffi.py:1112 (int wc_EccKeyToDer(ecc_key*, byte* output, word32 inLen);), that wolfSSL API has no curve flag at all -- only wc_EccPublicKeyToDer (used by the base EccPublic.encode_key, ciphers.py:1213) takes with_curve. The new parameter is therefore dead: it is accepted, type-checked, documented by its presence in the signature, and then dropped on the floor.

This is a behavioral regression, not just dead code. Before this PR, ecc_priv.encode_key(with_curve=False) raised TypeError: encode_key() takes 1 positional argument but 2 were given -- a loud, immediate failure. After this PR the same call silently returns curve-bearing DER, i.e. exactly the opposite of what the caller asked for. This is the LSP violation ty was warning about, converted from a noisy runtime error into a silent wrong answer.

It is also inconsistent with the rest of this same diff. The four other override mismatches touched here (EccPrivate.decode_key_raw at line 1375, EccPrivate.encode_key_raw at line 1412, Ed25519Private.encode_key at line 1683, Ed448Private.encode_key at line 1892) were all resolved with # ty: ignore[invalid-method-override], deliberately preserving the runtime signature. Only this one method had its signature altered, and it is the one case where doing so…

Fix: Revert the signature to def encode_key(self) -> bytes: and suppress with # ty: ignore[invalid-method-override], matching the four sibling methods fixed the same way in this diff. If the widened signature is intentionally kept for LSP substitutability, the parameter must not be a silent no-op: raise ValueError("with_curve=False is not supported for ECC private keys") when with_curve is falsy, and document the parameter in the docstring.

🟠 [Medium] _Hmac is no longer abstract after removing the _type abstractmethod

The diff deletes the @property @abstractmethod def _type(self) -> int: ... declaration and replaces it with a bare class-body annotation _type: int (line 460). A bare annotation creates no attribute and, critically, is not an abstract member -- so it removes the only thing that was keeping _Hmac abstract.

Walking the ABC bookkeeping: _Hash declares _init, _update, _final, _native_size, _native_type, digest_size, and new as abstract. _Hmac supplies concrete overrides or class attributes for every one of them (digest_size = None, _native_type = "Hmac *", _native_size = _ffi.sizeof("Hmac"), _init, _update, _final, new). With _type gone from __abstractmethods__, that set is now empty and _Hmac is instantiable.

Concretely: _Hmac(b"key") previously raised TypeError: Can't instantiate abstract class _Hmac with abstract method _type before any C resource was touched. It now proceeds into __init__, allocates the native object via _ffi.new(self._native_type), and only then dies at self._hmac_init(self._type, key) (line 479) with AttributeError: '_Hmac' object has no attribute '_type'. The same loss of enforcement applies to any future HMAC variant added to this file: forgetting _type = _TYPE_... used to be a class-instantiation-time error and is now a late AttributeError from inside __init__. _Hmac is a documented extension point (docs/mac.rst:25 has .. autoclass:: _Hmac), so this matters beyond internal use.

Fix: Restore an equivalent guard so a missing _type still fails early and legibly. Either add an __init_subclass__ check as shown, or keep _Hmac explicitly abstract (e.g. leave a trivial abstract member) so _Hmac itself cannot be constructed. At minimum, guard __init__ with an explicit check that produces a clear message instead of a raw AttributeError.

🟠 [Medium] New uv run ty check CI gate may never fail the build

The PR's stated purpose is to "allow to run ty check in the pipeline static checks step," but the step as written may be a no-op gate. pyproject.toml contains [tool.ty.rules] with all = "warn", which downgrades every ty rule from its default severity to warning level. ty check exits non-zero for error-level diagnostics; warning-level diagnostics require the --error-on-warning flag to affect the exit code. If that is the case here, the step will print diagnostics to the CI log and still exit 0, so the type regressions this PR just spent effort eliminating could silently reappear without turning CI red.

The multi-command run: | block itself is fine -- GitHub Actions uses bash -e {0} on Linux, so a failing uv run ruff check will still abort before ty check.

Fix: Verify the gate actually blocks: temporarily introduce a deliberate type error on the branch and confirm the job goes red. If it does not, either add --error-on-warning to the CI invocation or promote the rules that should be blocking from "warn" to "error" in [tool.ty.rules].

🔵 [Low] _type should be annotated ClassVar[int], not int

_type: int declares an instance variable, but every concrete subclass assigns it at class level -- HmacSha._type = _TYPE_SHA (line 533), HmacSha256._type = _TYPE_SHA256 (line 545), HmacSha384 (line 557), HmacSha512 (line 569) -- and wolfcrypt/hkdf.py reads it straight off the class object, never an instance: hash_cls._type at hkdf.py:70, hkdf.py:106, and hkdf.py:137, where hash_cls: type[_Hmac]. ClassVar[int] states the actual contract (a class-level constant selecting the wolfCrypt HMAC type id), makes class-object access unambiguous for checkers, and prevents a subclass from accidentally shadowing it per-instance. Worth doing since mypy is also in the dev dependency group and may treat class-object access to a plain instance annotation less permissively than ty.

Fix: Change the annotation to _type: ClassVar[int] and add ClassVar to the typing import at wolfcrypt/hashes.py:26.